COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	THIS FILE IS DRAFT #1 OF THE DIALNET PROTOCOLS.
C00003 00003		Motivation (or why this crock is the way it is)
C00008 00004		How data is transmitted over DIALnet
C00013 00005		How a connection is initiated
C00017 00006		How a connection is accepted
C00020 00007		How a process is terminated
C00023 ENDMK
C⊗;
THIS FILE IS DRAFT #1 OF THE DIALNET PROTOCOLS.

IT IS BEING SUPERCEDED BY THE SECOND DRAFT, WHICH IS IN PROGRESS.
	Motivation (or why this crock is the way it is)

[This file represents the current theory of the DIALnet protocols.  By no
 means have the protocols been inscribed upon stone tablets or even paper
 tablets!  So probably it all is going to end up totally different.]

While thinking over the protocols, I have been considering the type of
systems DIALnet is going to run on, and the type of systems DIALnet very
well may end up running on.  I decided that short-sightedness in the early
design of the protocols would pose unwarranted hinderances in the usage of
DIALnet in the future.  More importantly, I feel that it would be a mistake
to eschew a certain amount of hair on the flimsy basis that some computers
or some programmers today cannot use such hair.  The technology has been
changing at such a rapid rate that I feel it makes no sense to design around
a limitation of hardware that will go away in a few years, and similarly do
not want to reject a very elegant and powerful way of doing things because
my next door neighbor's 9-year-old kid brother cannot program this on his
1K 8080.

At the same time, there is the other extreme to consider; the problem of
implementing protocols that only the most learned of the programming wizards
can comprehend, not to mention implement.  We want DIALnet to be accessable
by the computing community at large, and would serve no good purpose by
presenting a series of nasty technical problems.  We also want to have
protocols that can be reasonably implemented on present-day hardware.  No
purpose is served by implementing protocols for a theoretical computer.

Next comes the questions of how transmission is going to happen at the
most elementary level.  I am not sure about this; since no decisions have
been made as to what modems are going to be used other than that we are
going to use 1200 baud over conventional phone lines.  Hence, I shall make
some assumptions that may or may not be reasonable, and if these assumptions
are changed, some of the thinking involved in the following discussion will
have to change as well.

Parts of the protocol are rather redundant in that both sides know what is
going to come next (on the sender's side, what it is required to send; on
the receiver's side, what it is to expect).  This is intentional.  The
motivation behind this is to remove ambiguity and to provide well-defined
transmissions between sites.  The intent is such that any spurious
transmissions are immediately seen and rejected as violations of protocol.
	How data is transmitted over DIALnet

Data is transmitted over DIALnet in 8-bit bytes with even parity (hence 9-bit
transmission) at a rate of 1200 baud.  Each host on DIALnet sends the other
host an allocation of how many bytes the other host may send before it must
stop and receive a larger allocation (a host that is confident of its
ability to handle continuous 1200 baud input may send an infinite allocation).
Each message, or packet, sent over DIALnet begins with a packet header and
ends with a packet trailer.  The header is used to identify the packet
contents and to supply the receiver with information such as the size of the
packet, the identification of the receiver's process which is to handle the
packet, etc.  The trailer supplies the receiver with a checksum for verifying
the correctness of the reception of the packet (I am considering an extremely
powerful checksumming technique that quite often enables recovery of the data
without requiring retransmission for this purpose).

Data that is not in 8 bit bytes must be split up into the appropriate number
of 8-bit bytes.

A packet header looks like the following (values are in octal):

0/	037		; always.  indicates start of packet.  any other
			; value is in violation of protocol.

1-4/	S process ID	; process ID of sender.  see below

5-10/	R process ID	; process ID of receiver.  see below

11-14/	byte count	; count of number of data bytes following.  as this
			; field is 32. bits long, plenty of room is allowed
			; for as unreasonably long as it is desired for
			; packets to be.

A packet trailer looks like the following: (again values are in octal):

0/	checksum	; checksum of all bytes sent INCLUDING the entire
			; contents of the packet header and trailer.

1/	037		; always.  indicates end of packet.  any other value
			; is in violation of protocol.

As it may have been noticed, this protocol likes using 32. bit values.  This
is since 32. bit quantities are convenient for many computers.  Even PDP-10's
which are 36. it machines can handle 32. bits with no problem, however this
is not generally true the other way around.  Also, 8. divides into 32. evenly
and so on.

A process ID is a 4 character (perhaps this could be expanded to 8 characters?
this is not convenient for PDP-10's though) ASCII string identifying the
process which is either sending or receiving the packet.  At the low level it
does not matter what is in these values, however, the high level protocols do
use the process ID's, so it is not alright to put any random value in them!
However, within limits an individual host is free to call its own process ID's
whatever it wants to, however it is obligated to use them once it has so
assigned them.  Process ID's are described in greated detail with the high
level protocols.
	How a connection is initiated

After a dialup connection has been made, the party initialiating
the connection (for historical purposes called the USER) must inform
the passive party receiving the connection (for similar hysterical
purposes called the SERVER) what the purpose of the connection is so
that the server may connect the user to the desired process at the
server's end.

It is intended that each individual process will have its own process
ID for connection purposes.  Since a server may wish to place a user
on a unique process after connection has been made, an connection
protocol has to be created so that the user ends up getting connected
to the proper process.

When a connection is first established, the server should provide the
user with a "go ahead" message [I don't know if I like this and so I'm
not going to elaborate more on it; perhaps this part can be flushed
entirely] after which the user has clearance to start sending protocol
messages.

The user sends the server a process connection request (PCR) packet of
the form:

0/	036		; always.  indicates start of PCR packet.  any
			; other value is in violation of protocol.  in
			; particular, a data packet may not be sent
			; until a PCR has been completed.

1-4/	U process ID	; the user's process ID.  no restriction is
			; placed on this value except that it must be
			; unique a single process at the user's end.
			; it is expected that this would be some
			; meaningful quantity to the user and perhaps
			; to the server.

5-10/	S process ID	; the server's process ID.  this is the ID of
			; the process on the server that is to spawn
			; a unique process for the user to perform the
			; user's desired task.  Currently assigned
			; server process ID's are:
			; MAIL		mailing service
			; SEND		line-at-a-time immediate person-
			;		to-person communication
			; TALK		character-at-a-time immediate
			;		person-to-person communication
			; FSTR		file storage service
			; FRTR		file retrieval service
			; TLNT		telnet-type service (ie, log in,
			;		etc.)

11/	checksum	; checksum of the ENTIRE packet [?? Is this
			; desirable?  maybe 4 bytes ??]

12/	036		; always.  indicates end of PCR packet.  any
			; other value is in violation of protocol.
	How a connection is accepted

When the server receives the PCR, it should reply with a PCA (process
connection acceptance) packet.  This is to inform the user of the
server's process ID to which all data packets should go.  A PCA packet
is in the form:

0/	035		; always.  indicates start of PCA packet.  any
			; other value is in violation of protocol.

1-4/	S process ID	; the process ID of the server.  this is the
			; process ID used in the PCR.  it is in violation
			; of protocol for any other value to appear here.

5-10/	U process ID	; the process ID of the user.  obviously, it is
			; the same as in the PCA (in fact, the user's
			; process ID is never changed).

11-14/	A process ID	; the process ID of the server's process assigned
			; to the user to handle the user's data packets.
			; this is the process ID the user should use in
			; further communications with the server for the
			; user's selected task.

15/	checksum	; checksum of the ENTIRE packet [?? necessary ??]

16/	035		; always.  indicates end of PCA packet.  any
			; other value is in violation of protocol.

If the server does not want to accept the connection, it responds with a
zero in the A process ID instead of a process ID.  Thus, a process ID of
zero is illegal.
	How a process is terminated

When a user process is finished with the connection, it should inform the
server of this.  Of course, the user could merely hang up the connection,
and indeed the server should flush the process in that event.  To properly
terminate a process (which is opposed to hanging up in that other processes
can be initiated or existing other processes on the phone connection).  A
terminate process packet looks like:

0/	034		; always.  indicates that process should be terminated.

1-4/	S process ID	; the process ID of the server.  this is the ID of the
			; process to be terminated.

5-10/	U process ID	; the process ID of the user.  after the termination
			; this process may no longer send data packets until
			; it has gone through PCR/PCA again

11/	checksum	; checksum of the ENTIRE packet

12/	034		; always.  indicates end of termination packet.  any
			; other value is in violation of protocol.

Following receipt of this packet, the process is terminated, and the server
and user process IDs are no longer in use and are available for other
process connections.

If no other connections are in use, the user OR the server, at its own option,
may hang up the phone line.

If the phone line is hung up while process connections are in effect, they are
all considered terminated.  Maybe will have reconnection option.